In the next few lessons, we'll be exploring Electron's session module, the concept of sessions in
an electron app is quite often misunderstood.
Essentially, a session is an object used for storing any sort of state data related to the web content
of a browser window.
This includes the HDP cache cookies Swype storages such as local storage or indexed DB and so on.
A session being a requirement for any browser window instant's created in an electron up then meaning
by default, electron creates a session for us, which is shared between all browser windows.
This session being referred to as the default session to see the default session we can access directly
on our main windows web contents all assigned to a variable sess equals main window dot web content
dot session.
Log that out.
I have the app running already.
So save.
Check the terminal there, an object of type session.
So to recap, a session is the store of any Web content data, meaning if we add an entry to local storage
in this browser window, that will be part of the current session and get stored in the default session
being used by main window to do this in the dev tools switch to the application tab, we see all the
various storage type supported by chromium here open the default local storage table.
Adding a key name with value electron, so this entry should now be stored and persistent in our default
session with the app restart by typing hours in the terminal.
And they're the local storage entry still exists, this being as the default session is persisted,
the second type of session being in memory only, but we'll see that in a minute.
Now, I mentioned that the default session gets created by electron and is shared across all the apps
browser windows.
So let's add a second window to demonstrate that I'll get rid of this log, create a new global variable
to reference our second window sec window, duplicate the main window constructor assigning to SEC window
with some slightly different dimensions.
Again, 800 by 600 with a slight offset to main window.
Just so we can see the two side by side X 200 y 200.
I'll use the same content index dot html.
Opened the dev tools panel for SEC window.
And finally duplicate that close to listener.
That should do.
So with a second window, let's reference it session also and compare it to the main window session,
remember, the default session is shared.
Latsis two equals SEC window dot web content dot session with a long message in which we can check if
main window and SEC window is in fact using the same session using JavaScript object class calling is
session and session to this being a simple function for checking where the two variables reference the
same object.
Save this.
And immediately we see that local storage key also exists on SEC window, meaning both Windows share
the same session, confirmed this in the terminal.
True.
So we now know how to access the default session, given a browser window instance, but we can also
get the default session directly from the session module.
I'll require that module from electron session.
Assigning to default session session, dot default session.
Same session object as both fees confirm this comparing session to default session save check the terminal.
And again, true, if you're working with multiple browser windows and a single default session, which
will be applicable for the majority of applications this session or default session, property is recommended
as a more logical convention.
With that said, you might not always want to use the default session instead.
Then we can create our own session objects and tell a browser window to use this customization in place
of the default session.
Customizations can have a number of uses.
The most common being the ability to get such a session from an external source and have the app content
in the same state as a second instance of the app.
Think of sinking an app between multiple devices.
For example, in Create a Window are assigned to a new variable customization.
Session the session module from partition with a single argument being the partition name, part one,
think of a partition then as a unit of storage, much like a hard drive partition.
In this case, we are creating such a partition to be used for our session objects data.
Right now, we're still not using this new session in any of our browser windows, but let's compare
it to the default session.
First object is comparing Sess or session to customization save.
We see both windows are still using the default section as they both contain this local storage entry,
check the terminal and this time we have false meaning.
The two objects compared isn't the same.
So let's tell SEC window to use our new customizations instead of the default one in this browser window
constructor set on the Web preferences object, this being constructor options for the browser Windows
Web contents session customization.
This variable URL format is a bit nicer.
Main window is still using the default session and SEC window is using our customization save.
And SEC window no longer contains that local storage entry as it's saved in the default section used
here.
I'll add an entry to SEC Windows Local Storage when name or window name SEC window.
This being stored on our custom session now, however, quit the app.
Restarted.
And the entry is gone, there's being, as we have two types of partitions for storing sessions persisted,
meaning saved to disk and memory partitions, memory partitions are only stored in memory and does not
get persisted between app restarts, which is what our custom sessions partition is at the moment.
Whilst the default session uses a persistent partition by default, again, some apps might have a use
for in memory sessions, but for the most part will probably want to save our session between restarts.
So let's change this to make a partition persisted.
It's as easy as prefixing the partition name with persist kolon.
Save.
This change, having reset the state of our Windows Dev tools back to the application tab, local storage,
add back that local storage entry when name.
SEC window.
Hours to restart.
And they're this time the session is persisted between app restarts, Electron also provides us a shorthand
property for creating and assigning custom sessions to a browser window instead of first creating the
session from a partition like we did here, we can assign and create the session partition directly
on the windows, where preferences all delete this.
Also comment out this comparison as session now no longer exists.
And then where we are signing the customization to SEC window change this to partition with the name
of the partition we want to use persist Kolon part one, meaning if this partition does not already
exist, create and use it.
Save.
There is no change SEC window still contains that local storage entry, so a persistent session exists
and can be retrieved by name at any point after it was created.
Again, a possible use case might include having multiple user sessions for a single instance.
But with that, we also need to be able to delete data from a session.
A few methods exist for this, but in our case we can call session.
So the default session, clear storage, data storage data being Cookie's local storage index, DB or
even service workers save that.
And this time our name entry is gone from the main window, as all of the storage data on the default
session was cleared, another method exists for clearing the sessions HTP cache, also clear cache.
Then taking a quick look through the docs sessions allows us to do a few things other than just store
data.
Again, all related to the content of the browser window.
For example, we can create network emulations, meaning slow the network down.
Generally good for development.
Handle permissions checks for things like using the camera, allowing notifications, etc., get the
user agent string or clear cached HDP authentication credentials and there's a few more we'll cover
later on.
In the next lesson, we'll take a look at cookies.
An important part of the session module.